The Digital Imaging and Communications in Medicine (DICOM) Structured Reporting (SR) standard, and the SR Documentation Model upon which it is based, improves the expressiveness, precision, and comparability of documentation of diagnostic images and waveforms. DICOM SR supports the interchange of expressive compound reports in which the critical features shown by images and waveforms can be denoted unambiguously by the observer, indexed, and retrieved selectively by subsequent reviewers. Findings may be expressed by the observer as text, codes, and numeric measurements, or via location coordinates of specific regions of interest within images or waveforms, or references to comparison images, sound, waveforms, curves, and previous report information. The observational and historical findings recorded by the observer may include any evidence referenced as part of an interpretation procedure.
Thus, DICOM SR supports not only the reporting of diagnostic observations, but the capability to document fully the evidence that evoked the observations. This capability provides significant new opportunities for large-scale collection of structured data for clinical research, training, and outcomes assessment as a routine by-product of diagnostic image and waveform interpretation, and facilitates the pooling of structured data for multi-center clinical trials and evaluations. See “Clinical Rationale for the SR Documentation Model and the DICOM Structured Reporting (SR) Standard”, Abstract, W. Dean Bidgood, Jr., © 1999.
The DICOM SR is based on a relational data technology, and has been standardized by the National Electrical Manufacturers Association (NEMA). DICOM SR supports not only the reporting of diagnostic observations, but can document fully the evidence that evoked the observations. This move toward structured, coded reports presents new care-improvement opportunities beyond mere storage and distribution. Coding medical information for selective retrieval allows computers to assist in processing the increasingly large amounts of clinical data collected during normal operation of a healthcare enterprise. When judiciously combined with knowledge-based information processing we can significantly enhance clinical decision-making.
As with any structured data in healthcare, benefits exist in outcome analysis and point-of-care applications. SR in its most general form is very flexible and the same content can be expressed in different forms and structures, hampering interoperability. Templates are a means to put additional constraints on an SR document to promote common formats for specific reporting applications. DICOM part 16 DCMR (DICOM Content Mapping Resource) [2] defines general SR templates and Mammography CAD SR IOD templates. Additional templates for other specialties are being developed such as:                Supplement 26: Ultrasound OB-GYN Procedure Reports        Supplement 66: Catheterization Lab SR SOP Classes        Supplement 71: Vascular Procedure Reports        Supplement 72: Echocardiography Procedure Reports        
Although the DICOM SR standard provides for a consistent reporting and recording scheme, the use of the information contained in a DICOM SR is limited to DICOM compliant applications that can process this information using the DICOM specific format. Application developers must be DICOM literate, and a methodology for deploying applications that interoperate with other applications outside the DICOM domain has not yet been developed.
In the computer industry, progress has been made in the use of standardized languages and methodologies that facilitate the use of information from a variety of sources by a variety of applications. A standard language that is widely used for processing content material is the World Wide Web Consortium (W3C) Extensible Markup Language (XML), which is derived from the Standard Generalized Markup Language (SGML), and is designed to describe data and its structure so that it can be easily transferred over a network and consistently processed by the receiver. Because XML is used to describe information as well as structure, it is particularly well suited as a data description language.
One of the particular strengths of XML is that it allows entire industries, academic disciplines, and professional organizations to develop sets of Document Type Definitions (DTDs) and Schemas that can serve to standardize the representation of information within those disciplines. Given a set of DTDs and Schemas, content material that is modeled in conformance with the DTDs and Schemas can be processed by applications that are developed for these DTDs and Schemas.
A further advantage of the use of XML is the wealth of tools that are available for the processing of XML-compatible data. Of particular significance, the “Extensible Stylesheet Language” (XSL) is a language for expressing stylesheets, and the “XSL Transformations” (XSLT) is a language for transforming XML documents into other XML documents. A stylesheet contains a set of template rules, which are used to match a pattern to a source document, or “source tree” and, when the appropriate match is found, to instantiate a template to a result document, or “result tree”. In this manner, XML information that is structured for one application can be relatively easily transformed into a different structure for another application.
As has become apparent from a variety of showcases like scientific assemblies and annual meetings of the Radiology Society of North America (RSNA), annual conferences and exhibitions of Healthcare Information and Management Systems Society (HIMSS), and various channels like technical conferences, standardization working group meetings, a large number of vendors have been doing encoding of DICOM SR in the XML since the DICOM SR was standardized in 2001 followed by a number of SR template supplements being developed.
Accordingly, with the extensive use of XML in representing DICOM SR reports, especially when SR Templates are used in generating a variety of SR XML documents, validation of SR XML documents against the SR templates becomes more and more important in promoting their precision, usage, and interoperability.
The constraints in SR Templates are complicated, making it a challenging task to validate SR documents against the SR Templates.
Validation of an XML document is considered at two levels: syntactic validation and semantic validation. Syntactic validation is mainly to check the structures of an XML document against its XML Schema or DTD. Semantic validation, on the other hand, mainly checks the non-structural constraints, in most cases, the content of an XML document. We already have XML schemas for the general SR Information Object Definitions (IODs). They can be used to validate the basic structures, DICOM tag information, and data types of SR XML documents.
We also have a mechanism to generate XML schemas for SR Templates. XML Schema can express the static or fixed value constraints specified in SR Templates. However, the dynamic value constraints and inter-relationship constraints specified in SR Templates cannot be expressed in W3C XML Schema 1.0. They are again highlighted below:                The Relation with Parent constraints;        The Context Group reference constraints;        The Parameter constraints; and        The Conditions (like the IFF statement and free text).        
Therefore, XML schemas of either the general SR or the Templates cannot validate SR documents against the constraints specified in the SR Templates. Semantic validation is needed to accomplish this task.
Several approaches have been proposed for semantic validation like Schematron and XincaML. One of the drawbacks of these solutions is that they cannot deal with the Parameters that are often used in SR Templates. We propose an approach of using XSLT—an XML technology from the W3C for doing semantic validation of SR XML documents against the SR Templates. XSLT was developed originally for transforming an XML document to another XML document. It supports parameterized XSLT templates besides XPath. The document function allows access to external XML documents other than the source document. These features are exactly those needed to deal with Parameter, Context Group reference, and Relation with Parent constraints. Another benefit is that the results can be represented in XML so that it also makes the validation results human readable.
Characteristics of SR Templates
“Templates are patterns that specify the Concept Names, Requirements, Conditions, Value Types, Value Multiplicity, Value Set restrictions, Relationship Types and other attributes of Content Items for a particular application.” 2 Templates are used to put additional constraints on an SR content tree (FIG. 1) to promote common formats and vocabularies for specific reporting applications. Templates specify not only what Content Items are required or optional but also what constraints are for Concept Names or Value Set Constraints, etc. Table 1 through Table 4 illustrates the complexity of SR Templates and how they work together to constrain SR documents. See: DICOM Supplement 26: OB-GYN Ultrasound Procedure Reports, Draft Final Text, Jan. 24, 2003, NEMA, Rosslyn, Va.
A template table has the same structure. A row number denotes each row of a Template Table. The first row is numbered 1 and subsequent rows are numbered in ascending order with increments of 1. This number denotes a row for convenient description as well as reference in conditions. The nesting level (NL) of Content Items is denoted by “>” symbols, one per level of nesting below the initial Source Content Item (of the Template). Relationship Type and Relationship Mode (Rel with Parent) constraints, if defined, are specified in this field. The Value Type field specifies the SR Value Type of the Content Item or conveys the word “INCLUDE” to indicate that another Template is to be included.
Any constraints on Concept Name are specified in this field as defined or enumerated coded entries, or as baseline or defined context groups. The VM field indicates the number of times that either a Content Item of the specified pattern or an included Template may appear in this position. The Requirement Type field specifies the requirements on the presence or absence of the Content Item or included Template. The Condition field specifies any conditions upon which presence or absence of the Content Item or its values depends. This field specifies any Concept Name(s) or Values upon which there are dependencies. Value Set Constraints, if any, are specified in this field as defined or enumerated coded entries, or as baseline or defined context groups.